Edited into the original comment, regarding ftl-sdk:
Currently, only YouNow is using the ftl-sdk as Mixer no longer exists and Restream dropped FTL support when Mixer went down.

@rsiv Is YouNow planning to continue using FTL and the ftl-sdk? Does YouNow have any interest in forking ftl-sdk to continue maintaining it?

Hey @RytoEX
Yes, we plan to continue using FTL and the ftl-sdk.
Let me check with our team regarding maintaining a fork.
Besides updating to a newer CMake, do you expect any other work to be required in the near term?

Hey @RytoEX
Yes, we plan to continue using FTL and the ftl-sdk.
Let me check with our team regarding maintaining a fork.
Besides updating to a newer CMake, do you expect any other work to be required in the near term?

@rsiv
I believe @notr1ch had previously submitted some issue reports to the https://github.com/mixer/ftl-sdk/ repo. He may be able to speak to those, but I'm not aware of anything else that we were seeking to modify. I came across the CMake issue and the mixer/ftl-sdk repo doesn't seem to be getting any updates, so we thought to reach out to you about it.

@RytoEX
I forked ftl-sdk and bumped CMake to 2.8.12: https://github.com/YouNow/ftl-sdk

I have left the following comment in the developer discussion with the Glimesh folk, I'm going to leave it here, so you can see it, too:

It's fine to bump it up to 3.2 (I don't think anyone ever built it with something older, not even Beam/Mixer), the only real reason why it's at 2.8 is because OBS Studio was at the time (which they forked into their Tachyon software, which later became the OBS-FTL fork with the dedicated Beam Service in it). It was also the oldest version that could generate the build files for the compilers that can build the code, and to tell developers using it, that versions that old will be fine (If I recall correctly, not really sure right now). CMake will to the best of my knowledge only ever emit a warning for this, unless something else in the CMakeList is very off. Most things that break are usually the automated testing facilities, simple builds like used in the FTL SDK use directives that have remained the same throughout all of CMake's life and aren't likely to change anytime soon. I would avoid changing this, who cares about a little warning, if you know and understand what it means. You can suppress it, and add a comment about why you're suppressing it next to the directive that does. Personally, I prefer legacy support (as in having it work, not that there's any tech support call center or something like that), but 🤷‍♀️

Given that CMake recently broke configs using explicit LANGUAGE flags, I am not keen to simply ignore their warning that "Compatibility with CMake < 2.8.12 will be removed from a future version of CMake." The CMake devs have made clear that they are willing to break builds that rely on deprecated functionality or functionality being used outside of their designed use case. Furthermore, warning spam can drown out actually useful warnings, so we have an incentive to correct warnings when possible, rather than simply suppress or ignore them. I don't think I'm going to change my mind on whether or not we should make this change where we can.

I made the changes to all subprojects we control. When the matter of one we didn't (ftl-sdk and its subprojects/dependencies) came up, I discussed with the team and we decided that the best thing to do would be to reach out to YouNow about it, given that they were, at the time, the only known service still using or planning to use FTL. As mentioned on #3834, this also revived an internal discussion about whether to maintain or drop FTL support, which has briefly been discussed on that PR.

Please direct further FTL discussion here: #4021